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© User interface tool. 



© A user interface tool provides means for presenting items for selection by a user of a data processing 
system and means for executing the selected items. Each item of the menus and dialogues is an individual and 
independent object in an object database, referred to as an interface object. These objects can be added or 
deleted independent of each other, allowing greater extendability and customisation of the interface. The data 
within each of the interface objects and the selections from a user determine which of the interface objects will 
make up any one of several logical frame presentations at any one time to be presented to a user. The interface 
tool of this invention is adaptable for use with any one of a plurality of graphic libraries for presenting the actual 
screen image of the logical frame presentation to the user. In addition, the interface tool utilises the message 

^ facilities of the system to present the elements of the interface in multiple languages. More specifically, the 
interface tool of this invention is used for managing the system resources of a data processing system by a 

CO user. 
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USER INTERFACE TOOL 

This invention relates to a user interface tool for a data processing system wherein all elements of the 
interface are represented as objects in an object-oriented database. 

The term system management refers to the facilities or tools used to manage the configurable domains 
that a user is exposed to in a data processing system environment. A domain may be those devices, users, 
5 distributed file system, subsystems, and networks in a system; where the system may extend beyond a 
single machine. The system management facilities for each of the configurable domains may include the 
means to configure the system components when components are added or deleted from a system, means 
to configure a data processing system within a network of other data processing systems, and/or means to 
diagnose failures in the system components or the system configuration, etc. Traditionally, system 
w management is treated as an ancillary element of an operating system environment; made up of an 
assortment of disjoint tools which collectively offer the administrator/user the ability to manage and monitor 
various aspects of the system. 

In order for a user to perform tasks within a data processing system, there must be an "interaction 
between the user and the data processing system. Instead of requiring the user to enter the data required 
15 by the processing system in the language that the processing system understands, user interfaces are 
created so that the user can enter data into the data processing system and receive information back in a 
language and facility that is easy for the user to understand and manipulate. These user interfaces are quite 
numerous and varied. 

Some dialogue managers are based on tag languages. Tag languages require a developer who is 

20 creating a screen to know a specific non-programming language. The tag language specifies the screen 
layout on a total screen by screen basis. Specifying the screen layout includes specifying strings that are to 
appear on the screen, specifying the allowed values for the fields within the screen, and specifying the 
actions to be taken by a user. In addition, the tag language for one complete screen also specifies the next 
total screen that is to appear subsequently. 

25 One user interface, used for performing system management tasks, groups system management tools 

based on their function, and presents to the user a hierarchy of menus, solicits inputs for required 
parameters, and executes the functions. This interface uses a database of tables to store information about 
menus and options. However, since many of the same options appear in many of the same menus, the 
database is required to maintain all of the possible permutations between the menus and options. Excessive 

30 storage requirements within this database are necessitated since data on each option and menu are stored 
repetitively throughout the database. Therefore, if a change to one of the options or menus is made, the 
database cannot be updated just once t but must be updated at all of the locations where instances of that 
data resides. No one table within the database is sufficient to define any single interface object or group of 
objects, such as a menu or options within that menu. 

35 In addition, there is no ability to discover or develop the system information daring the execution of the 

interface tool. Therefore all system resource attribute values presented to the user must be initialised at 
development time, and cannot reflect the true state of the system at the time of execution of the interface 
tool. Therefore, the validation of user input for parameter values must be checked against these values 
initialised at development instead of being checked against the values that are actually valid based on the 

40 runtime configuration of the system resource. Similarly, messages displayed in this interface tool are 
initialised in the database tables rather than arising from the workings of the system itself. 

Generally, to update or change the interface database, it must be locked until changes are complete. 
This means that the database can not be modified until the end of the interface tool session. Any 
modifications made to the database through the interface tool are not immediately reflected in the interface 

45 tool until the next session of the interface tool. In addition, only system administrators typically are ailov/ed 
to modify the database. 

Users generally are required to enter the hierarchy of the interface tool at a specified point This 
requires that a user be presented a sequence of preliminary menus before the menu pertinent to the users 
task is presented. 

so Typically, these known interfaces are bound to one graphic representation. This decreases the - 
interface's portability to other systems having other graphic libraries. In addition, the interface database 
must be rewritten or another database completely redeveloped if the menus, options, messages, etc., are to 
support scr en presentations in multiple languages. 

Also, -in some interface tools, the actions to be performed in order to operate the tool are mixed 
together with the jobs to be performed by the functional layer in menus. For example, the functions "exit", 
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"go to next screen" "go to pr vious screen are contained within the menus and not the interface tool. As 
a result, if an administrator adds new menus, these functions must be included. Otherwise, if they are 
excluded, the user has no means for escaping from the interface tool. 

Therefore in accordance with the present invention ther, is provided a user interface tool having means 
s for presenting items for selection by a user of a data processing system for execution of the selected items, 
the interface tool comprising: means for representing a plurality of interface objects in an object database; 
and means for dynamically associating different ones of the interface objects into a plurality of logical frame 
presentations based upon the data within each of the different ones of the interface objects. 

The user interface is represented in an object database, it enables each element of a screen to be 
io represented as an object in an object database. 

In accordance with a preferred feature of the invention the interface tool further comprises means for 
managing a screen presentation of the objects and a user interaction with the objects based upon the data 
within at least one of the plurality of interface objects. 

Screen presentations are thereby created of an arbitrary number of elements. 
is The space needed for the storage of the interface database is minimized by building screens from 
reusable interface data objects. 

According to a preferred feature of the invention at least one of the plurality of interface objects 
represents at least one attribute of at least one system resource. The interface tool can. then comprise 
means for utilising a current value of the at least one attribute of the at least one system resource for 
20 presentation to the user. 

Preferably the interface tool further comprises means for utilising at least one instance of at least one of 
the system resources for presentation to the user for informing the user of an availability of the instance of 
the system resource. The interface tool can then further comprise means for allowing the user to select the 
instance of the system resource presented to the user. 
25 According to another preferred feature of the invention the interface tool further comprises means for 
utilising at least one instance of at least one of the system resources for presentation to the user for 
informing the user of an availability of the instance of the system resource. The interface may also 
comprise means for allowing the user to select the instance of the system resource presented to the user. 

According to another preferred feature of the invention at least two of the plurality of interface objects 
30 represent a hierarchical relationship between components of the data processing system based upon the 
data within each of the at least-two interface objects. 

The invention enables menus to be created dynamically during the execution of the interface tool from 
self identifying independent interface data objects. 

According to another preferred feature of the invention the interface objects are dynamically associated 
35 according to the hierarchical relationship represented within each of the at least two interface objects. 

According to another preferred feature of the invention the interface tool further comprises means for 
directly entering the hierarchy of interface objects at least one of a plurality of locations within the hierarchy. 

A fast path is thereby provided into the hierarchy to obviate traversal of the entire hierarchy. 

Different administrative views are provided by utilising access control policies which apply to the 
40 interface objects. 

According to another preferred feature of the invention the interface tool further comprises means for 
constructing a command by associating at least one user input value with an option within the at least one 
of the interface objects. The interface may also comprises means for executing the constructed command 
and means for logging the executed command for later re-execution. 
45 According to another preferred feature of the invention the means for constructing and executing does 
so for a command based on a current state of the data processing system, a plurality of user selections, 
and the data within the interface objects. 

The user interface tool interacts dynamically with the system to present to the user a current state of 
the system instead of preinitialised information of the system. 
50 According to another preferred feature of the invention the interface tool further comprises means for 
retrieving the objects from the object database in response to the user selected item. 

According to another preferred feature of the invention the interface tool further comprises means for 
iteratively presenting the interface objects to the user dependent upon a plurality of user selections and the 
data within the interface objects. 
55 According to another preferred feature of the invention the interface tool further comprises means for 
accessing at least one interface object from a plurality of screen presentations. 

According to another preferred feature of the invention the interface tool further comprises means for 
accessing at least one screen presentation from a plurality of interface objects. 
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According to another preferred feature of the invention the interface tool further comprises means for 
altering the interface object database from within th int rfac during a session of ex cution of the interface, 
and means for r fleeting the altered interface during the same session of execution of the interface. 

According to another preferred feature of the invention the interface tool further comprises means for 
5 altering the interface object database by creating at least one new interface object. 

Thus, interactive changes are allowed to the interface database during the execution of the interface 
tool which are reflected during this same session of execution. 

According to another preferred feature of the invention the interface tool further comprises means for 
displaying the logical frame presentations by a plurality of graphical libraries. 
iq Independent multiple graphical libraries are thereby supported. 

According to another preferred feature of the invention the interface tool further comprises means, 
within the interface data objects, for representing the items in the logical frame presentation in at least one 
of a plurality of ways dependent upon a graphical context 

According to another preferred feature of the invention the interface tool further comprises means. 
75 within the interface data objects, for representing the items in the logical frame presentation in at least one 
of a plurality of ways dependent upon a linguistic context. 

The message facilities of the system are utilised to present the elements of the interface in multiple 
languages. 

According to another preferred feature of the invention the interface tool further comprises means for 
20 accessing a screen library having means for indicating to the user a number of the items in the logical 
frame presentation currently outside of a visual screen presentation to the user. 

Users of the system are allowed to create new interface objects, and to modify existing objects based 
upon their access permission to them. 

Therefore, according to another preferred feature of the invention the interface tool further comprises 
25 means for providing at least one logical frame presentation dependent upon at least one access control 
policy applied to the plurality of interface objects. 

According to another aspect of the invention there is provided a data processing system comprising a 
user interface tool according to the invention. 

According to yet another aspect of the invention there is provided a method for presenting items for 
30 selection by a user of a data processing system, the method comprising: representing a plurality of 
interface objects in an object database; and dynamically associating different ones of the interface objects 
into a plurality of logical frame presentations based upon the data within each of the different ones of the 
interface objects. 

An embodiment of the invention will be described in more detail below with reference to the 
35 accompanying drawings wherein, 

fig. 1 A shows the progress of work from a top menu to the execution of a job from a dialogue, 
fig. 1B is a block diagram of the interface tool of this embodiment retrieving interface objects from an 
object database for dynamically creating logical frame presentations for display to a user by a plurality of 
graphic libraries. 

40 Fig. 2A shows the use of the interface objects in performing a system management job for a system 

resource. 

Hg. 2B shows the use of the interface objects in performing a system management job for another 
system resource. 

Fig. 3 illustrates the dynamic traversal through the interface objects. 
45 Fig. 4A - 4C is a flow chart showing the traversal of the interface tool through the topology of the 

system. 

Fig. 5A illustrates an alias mend object pointing to another menu for creating a fast path into the 
hierarchy. 

Fig. 5B illustrates an alias menu object pointing to a name selector for creating a fast path into the 
50 hierarchy. 

Fig. 5C illustrates an alias menu object pointing to a dialogue for creating a fast path into the 
hierarchy. 

Fig. 6A illustrates the hierarchy of system management menu option interface objects. 
Fig. 6B illustrates the hierarchy of devices menu option objects within the hierarchy of the system 
55 management interface objects. 

Fig. 6C is a further exploded view of the hierarchy shown in Fig. 6A and Fig. 6B. 
There are three general types of objects in the interface database: menu, name card (i.e., name select), 
and dialogue. They are differentiated by the role each plays in the collection of information, but do not 
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necessarily differ in presentation. In brief, the menu allows the user to refine and define the job that is 
required. The name card allows the user to specify a specific instance of a resources class either to which 
the user wishes to apply changes or with which the user wants to work/plan/model, etc. The dialogue allows 
the user to specify detailed information about instances of resources. The interface tool of this embodiment 
s may use combinations of these three types in order to collect all the required information before executing 
the application layer functions. For certain paths, one or more of these types may be unnecessary. The 
data objects themselves tell the interface tool code which objects come next in the path to the desire end 
function. 

The three classes of data objects in the interface tool are functional classes, and are not meant to have 
70 any set. specific correlation to presentation types or methods. In addition, a data object class may be 

present to interface tool but have no displayed correlation to the user. 

The term, "menu" is not meant to connote any particular screen appearance, or even to suggest that 

items are presented in a list of any form. "Menu" will be used to signify a means of diminishing the scope 

of either the object or the action (the noun or the verb) which is managed. 
75 The user is in a menu as long as the user is further refining the management job. The menu could take 

the form of a choice from a list, objects that may be opened for further detail, zooming in our out. 

movement through rooms, or whatever metaphor is appropriate. Once the job has been sufficiently defined, 

then the user leaves the realm of the menu for the dialogue. Note that the purpose of a menu is to get to a 

dialogue. 

20 Menus do not execute the end job, but merely carry the. user through to the job. Some functions do get 
executed, however, during passage through menus. These functions can be thought of as facilitating or 
lateral functions. They may be used to validate choices, present possible candidates for selection, and give 
help to the user. In general, then, these lateral functions.do cross over to the application layer to execute 
specified functions. However, these crosses are made to gather information for the user during the 

25 progression to the main job. As such, these facilitating functions are generally "read only" function. 
Passage through menus does not result in change to the application or system database. 

A menu is not a predefined entity, but rather a snapshot of all independent end user data objects that 
are found in the database at the time that the user enters the environment of one particular menu. The 
subset that is "found" at any one time is the set that meets a search criteria by means of a key field. This 

30 is an essential requirement for third-party extendibility of the interface. End user data objects may be easily 
added or deleted from the database without undue effect on other objects. 

Menu interface data objects are arranged into a hierarchy which is similar but necessarily equal to the 
hierarchy of system resource data objects. The hierarchy of menu tasks represents the most convenient 
and usable view of the system resources to the user. 

35 Fig. 6A, 6B, and 6C illustrates a portion of the hierarchy which exhibits the salient characteristics of the 
interface tool hierarchy. The menu objects 902-909, Fig. 6A, appear together in a logical frame presentation 
by virtue of sharing the same search key. Fig. 6B illustrates the branch of the hierarchy that would be 
available for the traversal if data object 903, Fig. 6A, were selected by the user. Menu interface data objects 
916 - 926, Fig. 6B appear together in a logical frame presentation by virtue of sharing the same search key. 

40 Objects 927-934 would appear together in a logical frame presentation if object 916 were selected. If object 
932 were selected, objects 935-937 would be available for selection. These are the same objects that 
appear on Fig. 6A in a logical frame presentation which is reached through a different selection path 
through the hierarchy. Fig. 6C shows a continuation of the branch available through selection of menu 
object 926, Fig. 6B. Objects 936 and 937, Fig: 6C, lead to different branches of menus. However, because 

45 TCP/IP is available to the user for configuration on either adapter, some menu objects 959, 960, Fig. 6C, 
are shared between the two branches. Menu object 906, Fig. 6A, is repeated on Fig. 6C. Its selection 
causes the presentation of object 939 and 940. The selection of menu object 939 results in a logical frame 
presentation which includes object 955 and 945. Object 955 is also contained in a logical frame presentation 
arrived at by the selection of object 954. Object 945 is also contained in a logical frame presentation arrived 

so at by the selection. 

The information contained in each menu object is sufficient to do the following: 1) present the menu 
item (the actual visual representation is left a screen library); 2) point to a subsequent (set of) bbject(s); and 
3) give help on the menu item. 

The menu object class 200 is shown in Table I (see appendix). The id 202 is the name of the object. 
55 This filed holds information sufficient to provide a search key by means of which this object is pointed to by 
the previous level object, thereby determining this object's participation with other objects in a group. This 
field may be externalised as a fast path id. 

The id seq num 203 indicates the order in which the objects of the menu will be displayed. The 
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next_jd 204 indicates the id of the next object for which to search if this item is selected. The field text 206 
describes the task to be presented to the user. The text_ msg_file 206 is the message facffities catalogue 
for the string, text. The text_msg_set field 207 is the message facilities set id for the string, text. Set ids 
are assigned by message services. The text__msg_id field 208 is the message facilities message id for the 
5 string, name. The next_type filed 209 indicates the type of the next object if this item is selected. Allowed 
values are "menu", "name", "dialogue", and "info". The alias field 210 indicates whether or not this menu 
object is a fast path pointer to another menu object Allowed values are 'yes B and "no". For a menu object 
which is an alias, the following convention applies: the objects next_Jd 204 and id_seq_num 203 will be 
used to find the menu object which will point to the menu desired. The heip_msg_id 211 indicates the tag 
jo number for the contextual help for the object. 

A dialogue is a composite of elements (as represented individually in data objects) that are found to be 
related at any one time. Therefore, it may be thought of as an array of structures, each element of which 
corresponds to a piece of information (parameter) that will be passed to the function which is the end job of 
the dialogue. Although the elements may vary widely in their graphic representations, the information 
75 contained in them is structured in the same way and is sufficient to do the . following: 1) present the dialogue 
item (proper representation is left to the graphical/text library): 2) point to a function to be executed; 3) 
present and collect choices (values); and 4) give help. 

The dialogue element objects have both a "question" (id) and an "answer" (value) part The answer 
part may have a tentative answer to suggest to the user, i.e. a default or current value. These two parts may 
20 have very different origins. It is necessary that the question be initialised when the dialogue object is 
developed. With it are initialised all of the other fields in the data object, with the (possible) exception of the 
answer. The answer may have no suggested value, or it may have a limited set of possible values. 
However, if the answer is dependent on the current state of the system, then it must be "discovered" at run 
time. The discovery process is detailed below. 
25 The "question" mentioned above may be no more than implied by the very presence of the element in 
the dialogue. For example, if the metaphor of the dialogue called for a dial, the elements of the dial, namely 
the face and the needle, would each be elements in the dialogue. Upon entry into that environment, the use 
is not confronted with a literal question. The question, "what is the desired setting of the needle?" is implied 
by the existence of the needle. The answer (value) would be given a current (input) value, which is 
30 discovered as detailed below. The user manipulates the needle to the desired setting, and that setting now 
becomes the output value of the data object. The new setting is received as a parameter when the interface 
tool executes the proper function to accomplish the change. 

To create a dialogue on the screen, the interface tool searches for keyed data objects (the key having 
been supplied from the previous object' s "next" field), chooses appropriate representations for the data 
35 objects (according to the current metaphor and/or NLS environment), orders the data objects according to 
their self-stated relationships to other possible objects, and prepares to present then to the user. However, 
some aspects of the data objects (such as current vaiues) may be missing. At this time, the interface tool 
invokes application layer functions to discover current configuration values. The names of these functions, 
as well, are contained within the dialogue data objects. 
40 The dialogue is represented by two classes of data objects. The header object represents the end job 
and is sufficient in itself to effect the application function database, thereby effecting real changes in the 
system. For each header object, there are one or more element objects. Each element presents one item ,of 
the metaphor, one resource, one parameter, one choice, one value, etc. 

While all menus lead to a dialogue header object (that really gets the work done), not all dialogue 
45 header objects lead to dialogue element objects. When the job is sufficiently defined ("diminished") by 
menus, there may be no need for further interaction with the user. In this case, the dialogue header will 
suffice, and the function will be dispatched without further ado. However, in other cases, more detailed 
information (choices) will need to be solicited from the user (or at least presented to the user for possible 
change). 

so The distinction between dialogues that contain headers only and those that contain elements, as well, 
can be either functional, stylistic, or contextual. For example, a request to list the instances of a resource is 
usually an end in itself, and would not need further elaboration via dialogue element data objects. The 
function to accomplish this could be immediately executed. (It, in turn, might send back these data 
elements to be located in the dialogue environment) If the user desires, on the other hand, to change 

55 characteristics of a resource, e.g. an alert message, then there would be (at least) one dialogue element, 
the value of which is the current message. The user could change this as the user pleased and then the 
function contained in the header would cause the change to occur. Resources with multiple characteristics 
which can be changed would need a separate element data object for each one. All, however, are united 
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under the single header. The distinction between the case in which the header is sufficient and th case in 
which it must be supported by multiple elements is a functional one. In cases where thee is never a 
function need for elements, they would not be defined. 

In contrast is the case in which one single function may require the further detailed elaboration of the 

5 element objects or it may not. If the user wishes to add a resource of a known type, the interface tool may 
use the context, style, or security level currently active to determine whether the user-definable characteris- 
tics of the resource are presented to the user for perusal or possible change at the time that the resource is 
added. At some levels, it might be considered inappropriate or annoying to present such details, while at 
other levels it would be essential. In cases where the distinction is not functional, the element objects 

10 should be defined and the decision left up to the interface tool. 

The dialogue header object class 400 is shown in Table III. The id 402 is the id or "name" of the object. 
The field option__id 403 is the id of the dialogue fields (sm__cmd_option) to which the header refers. The 
field has_name_select 405 indicates that the dialogue was or was not preceded by a name selector. 
Allowed values are "yes" and "no". The name 404 describes the job and is used as the title of the 

75 dialogue. The name__msg_file 406 is the message facilities catalogue for the string, name. The field 
name_msg_set 4Q7 is the message facilities set id for the string, name. The field name_msg_id 410 is 
the message facilities id for the string, name. The field cmd_to_exec 408 is the operating system 
command which executes the job of the dialogue. 

The field ask 409 indicates whether or not the user should be asked to reconsider the user's choice to 

20 execute a job (i.e. task). This is useful for such jobs as "DELETE", where a system resource is being 
deleted. Often, reconsideration is necessary even when there is no displayable dialogue associated with the 
job. If this is the case, a ghost dialogue is utilised. The field ghost 41 1 indicates whether or not there is a 
displayable dialogue associated with this job. If there, is no further information that needs to be solicited 
from the user, there is probably no need for a dialogue. In this case, the cmd_to_exec 408 is immediately 

25 executed. Allowed values for the field ghost 411 are "yes" or "no". Allowed values for the field ask 409 are 
n yes n and "no". 

The field exec_mode 413 indicates whether a command will be executed with stdin/stdout/stderr 
redirected through the interface tool (sm_default), or will inherit stdin/stdout/stderr for independent screen 
management (sm_fork__exec). The field cmd_Jo_discover 412 is the operating system command used to 

30 discover either the default or the current values of the object being manipulated. This command is executed 
before the dialogue is displayed, and its stdout is retrieved. The headers of the output columns will be used 
to match values with fields. The field cmd__to_discover_postfix 414 indicates the postfix to be used with 
the command_to__discover. There are three allowed values. The first is only used when there is a name 
selector associated with the dialogue. The value sm_postfix — raw indicates that the name entered into the 

35 name selector panel is to be used with this command. The value sm_postfix_cooked indicates that the 
name from the selector panel was typed by a cmd__to_classify, and that the output from that classifying 
command should be used with the cmd_to_discover. The value sm__postfix_empty indicates that there is 
not postfix for the cmd_Jo_discover. 

The field name_size 41 5 indicates the width of the field names for the dialogues. If this field is 0, 

40 default formatting is utilised. The field value_size 416 indicates the width of the field values for the 
dialogue. If this field is 0, the default formatting will be used. The field help__msg__id 417 indicates the tag 
number for the contextual help for the entire dialogue. 

The dialogue object class 300 is shown in Table II. The field id 302 is the id or "name" of the object. All 
objects (fields) that are to appear together in one dialogue must have the same id. The id_seq__num 303 

45 insures that the objects (fields) of the dialogue will be displayed in sequence. All character values are 
sequenced by code point When this object is used for a name selector, this field is 0. The 

disc field name 304 indicates the header string in the stdout from the cmd_to_jdiscover whose value is 

to be associated with this object. It is the logical equivalent of the name field 305, but may be a more 
abbreviated form. This field is to be coordinated with the stdout of the cmd_to_discover 412. To indicate 

so that the value for this object is to come from the (raw/cooked) name instead of the cmd__to__discover, this 
field should be set to "rawname" or "cookedname". When this object is used for a name selector, this field 
is reserved and is set to null. The name 305 field is the string which will appear on the screen as the field 

name. It is the "question" portion and usually correlates to a parameter of the cmd_Jo exec, i.e., it is the 

natural language explanation of an option, parameter, flag. etc. The name__msg_file 306 is the message 

55 facilities catalogue for the string, name. The name_msg__set 307 is the message facilities set id for the 

string, name. The name msg id 308 is the message facilities message id for the string, name. 

The op_type field 309 indicates the screen management method for this object. The allowed values 
are as follows. The value sm list entry indicates that, although 0 or 1 values are presented to the user, a 
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list is available for this field. The list is produced by the cmd_to_Jist when the user indicates the US1 
function. The value sm_ ring_entry indicates that the field has multiple values through which the user may 
cycle. AH ring fields may be also shown as lists (i.e. all choices at one time, within the limits of the screen). 
The entry_type 321 indicates the screen management method for this object The value 
5 sm_Jext_entry indicates that the user may type alphanumeric input into the field. The value 
sm_numeric_entry indicates that the user may enter only numeric data. The value sm__ hex entry 
indicates that the user may enter only hexadecimal data. The value sm_file_entry indicates that the user 
may enter only a file name. The value sm_no__entry indicates that the field is information onty. 

The field entry_size 322 indicates the maximum number of bytes that the user may enter into the 
jo value field. If this number is 0, then no upper limit is requested. The field required 310 indicates whether 
the field must always be sent with the cmd_to_exec, regardless of whether the user has changed the 
value. Ordinarily, an unchanged field field is not sent with the command. Allowed values are "yes" and 
"no". When this object is used for a name selector, this field is reserved, and is set to null. 

The field prefix 31 1 indicates the prefix or flag that is to be sent with the value field in the execution of 
is the cmd_to_exec. It may be set to null for no flag or n -f" where "f B indicates the flag to be used. In both 
of these cases, the value and the flag will be collected on the first pass. Also, it may be set to ?- n . which 
indicates that there is no flag and the value should be collected on the second pass. When this object is 
used as a name selector, this field is reserved and is set to null. 

The cmd_to_Jist_mode 313 indicates how much of an item selected from a list should be used. 
20 Allowed values are sm_first_fieid and sm_all_fields. If the command returns a range rather than a list, 
the value of this field should be snwange. ranges are not selectable, but are for information only. The 
cmd_to_list 312 indicates the operating system command, if one exists, which supplies a list of 
candidates for the value field. The field cmd_to_Jist_postfix 323 indicates the postfix to be used with the 
cmd_to_list. There are three allowed values; the first may be used only when there is a name selector 
25 associated with the dialogue. The sm_postfix_raw indicates that the name entered into the name selector 
panel is to be used with the command. The value sm_postfix_cooked indicates the the output from the 
name selector's cmd_to__classify should be used with the command. The value sm_postfix_empty 
indicates that there is no postfix for the command. When this object is used for a name selector, this field is 
reserved and should be set to null. 
30 The field multi__select indicates whether the user may make multiple selections from the cmd_Jo_list. 
Allowed values are "yes" and"no". The field value_index 314 is a zero-origin index indicating the default 
value in the sequence of values specified in the value field if the object is a ring. 

The field disp_va!ues 315 provides the current, default, or allowed values which are to be presented to 
the user at the beginning of a dialogue. This field may be initialised when the object is developed or 
35 discovered at runtime by the cmd_to__discover. The values_jnsg_file 316 is the message facilities 
catalogue for the string, disp_values. If these values are initialised when the object is developed. The 
values_msg__set field 317 is the message facilities set id for the string, disp_vaJues, if these values are 
initialised at development time. The field values_msg_id 318 is the message facilities message id for the 
string, disp_va!ues, if these values are initialised when the object is developed. 
40 The field aix_value 319 indicates the operating system command values that are equivalent to the 
natural language disp_values presented in a ring field initialised at development time. When this object is 
used for a name selector, this field is reserved and should be set to null. The help_msg_id 320 indicates 
the tag number for the contextual help for the object. The field cmd_to_validate 325 is used to validate 
user input values for a single field. 
45 Name selector objects are used for gathering the instance of an object upon which an application layer 
function is to be performed. In other words, they select the direct object of trie function. The list function in 
the name card supplies the run-time choices from which the user may select. 

Name selector objects supply parameters used in the execution of succeeding end or lateral functions. 
Name selector objects are also used to direct the interface layer to different succeeding interface data 
so objects, thereby altering the oth taken towards an end function. 

For example, if the user wishes to connect a certain printer to a certain queue, the interface tool must 
know exactly which printer (not just which type) is to be connected. In other words, it needs a logical 
instance name. It solicits this information by a name selector object. The interface objects cannot be 
initialised with a list of possible printer names because this information depends on the current configuration 
55 of the system. Therefore, the name selector object defines the application layer function which will retrieve 
the list of printers of the desired type that are known to the system (i.e. represented in the system 
database). Name select objects carry out a list and select function. The name selected is needed as a 
parameter to the end job function. 
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At a higher level, name selector objects may be used to list types of physical printers rather than 
names of logical printers. Again, the interface objects cannot contain this list, but must contain the name of 
the function to execute in the application layer to get this information. When the user chooses between 
types in a resource class, the choice often has implication on the choice of subsequent data objects. Not all 
s types of printers will operate (connect/configure, etc.) in the same way. Therefore, the type selected will be 
used in some way (perhaps concatenation) to find the next interface object(s). 

In general, the function to list is automatically executed to present the user with only valid choices. On 
the other hand, if the list of choices is so long that the extensive scrolling of the presentation space in order 
to present the entire list would only annoy the user, or the list of candidates is almost limitless, or the user 
io is likely to know the name of the object that the user wants to select, the shortest path is to represent the 
name select function to the user with the ability to simply key in the instance, offering the listing feature as 
an option. This case will often occur in working with file systems where every file might need to be listed as 
a candidate. 

The name select object class 600 is further described with reference to Table IV. The id 602 is the id or 

75 "name" of the object. The field next_id 603 indicates the id of the sm_cmd__hdr object which this name 

selector precedes. The field option id 605 is the sm cmd opt for this name selector. The field name 604 

is the title of the name selector screen. The field name__msg_file 606 is the message facilities catalogue 
for the string, name. The field name_msg_set 607 is the message facilities set id for the string, name. The 
field name msg id 608 is the message facilities message id for the string, name. 

20 The field type 609 indicates the method to be used to process the name selected. The value 
sm_just_name indicates that the name selected is merely passed to the dialogue. In this case, the 
next_id field is a fully defined string, initialised at the time the object is developed. The cmd_to_classify 
is not needed and is therefore null. There is no need to wait until an instance is selected to decide which 
dialogue need be presented. The value sm raw name indicates that the name selected is concatenated 

25 with the string in next_id to produce the search key for the dialogue. An example of this case is seen in a 
TCP/IP menu where the name selection "Ethernet" calls up a different dialogue than the name selection of 
"Token". In this case, the next id is defined partially at development, and partially at runtime. Again, 

cmd to__classify is not needed and therefore null. The value sm_cooked name indicates that the name 

selected is not sufficient for the determination of which dialogue next to present. An example of this is with 

30 printers, where the selection of an instance, "IpO", does not give enough information for the selection of the 

next dialogue because "Ipo" is of unknown type. In this case, next id gets the value of next id + the 

stdout returned from the cmd to classify, which is sent the name selected. 

The ghost field 610 indicates whether or not to display the name field 604 or go straight to listing 
produced by the cmd__to_list. The cmd_to_classify 614 indicates the operating system command, if one 

35 is needed, that is to be used to classify the value of the name field 604 of the sm cmd_opt record for this 

name selector. The field help_msg_Jd 611 indicates the tag number for the contextual help for the object. 

Figure 1A shows the progression of work, from a top menu 1A down to the execution of work. All work 
is executed out of a dialogue 14. Although the lateral help 2 and list 4 do not contribute to the progression, 
they do assist the user to make the progression by offering help and lists of possible candidates off of any 

40 item. A user enters at a top menu 1A and traverses through several other possible menus until the user 
gets to a name select 12, which is optional. Next is the dialogue 14. Each of these three steps: menu 1, 
name select 12 and dialogue 14 appear differently and have different properties. A dialogue is the actual 
interaction with a user, and it typically consists of attributes of the system resource. The user then enters or 
selects values for the attributes, completes alt the responses for the dialogue, and then indicates that the 

45 user is ready to run the task which is then executed. The output of the command is directed to an output 
frame. Since the helps 2 and the lists 4 are contextual, a user can get help on the whole menu, any 
individual item in the menu, the whole dialogue, or any individual item in the dialogue. 

Each interface menu object, called a system management tool menu option, is represented in a menu. 
A menu is not static, but rather it is a collection of menu options that were found in an object database at 

50 any one time to have the same search key. This is important in extending the function of the application, or 
the shell, because this allows a user to put in a new item in the menu by merely adding a new object, a 
new menu option, with the same search key as the other items on the menu that the user wants it to be 
included within. The next time that the user ran the shell, there would be an extra item (being the one just 
added) that would appear in the menu. Therefore, a menu is not static. Instead, it comprises all of the 

55 objects that happened to have met the search criteria at any one time. Users can thereby extend this 
interface tool by selecting a location in the tree where they want to hook into the shell, and by meeting the 
search criteria at that location. 

A general flow for traversing through the topology of the system is shown with reference to Fig. 4A - 
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Fig. 4C. The Id of the top menu is used as priming input to the menu processing module which uses the id 
to search for menu interface objects in the object data manager, step 801. The proper representation for the 
menu interface object is determined with reference to the linguistic and/or graphical environment. All objects 
found to meet the id key are sent for display to a screen library which enforces conformity by narrowing the 
5 interface to multiple graphical libraries, step 802. The collection of objects sent to the screen library from 
the interface tool is referred to herein as the logical frame presentation, since it has not yet been displayed 
to the user. 

The screen library collects user input until a user selection is made, and sends the selection back to tfce 
menu processing unit, step 803. The menu processing module examines the menu interface object that 
w represents the user selection, step 804. If the next type indicates a menu, step 805. then the next id is 
passed in recursive call, step 806, to the menu processing module. This loop continues until the next type 
is not a menu. 

If the next type is found to be a name selector, step 807. then the name select processing module uses 
the id to search for a name selector interface object in the object data manager, step 808. The proper 

75 representation for the name selector interface object is determined with reference to the linguistic and/or 
graphical environment The representation is sent for display to a screen, library which enforces conformity 
by narrowing the interface to multiple graphical libraries, step 809. The screen library collects user input 
until a user selection is made, and sends the selection back to the name selector processing module, step 
810. The name select processing module examines the name selector interface object to determine the 

20 interaction between the next id and the user selection in determining the search key for the dialogue 
header, step 811. There are three methods for performing this interaction. The first method indicates that 
the user selection is merely passed to the dialogue. In this case, the next_id field is a fully defined string. 
The command_to_classify is not needed and is therefore null. The user selection has no influence on the 
dialogue header object. The second method indicates that the name selected is concatenated with the 

25 string in next_id to* produce the search key for the dialogue. In this case, the next_id is defined partially 
by the developer of the name select interface object and partially by the user based upon the user's 
selection. 

Again, the command_Jo_classify is not needed and is therefore null. The third method indicates that 
the user selection is not sufficient for the determination of which dialogue next to present. In this case the 
30 name select processing module sends the user input as a parameter to the command_to_classrfy, and 
receives as output from the command a type, step 812. The user selected name and the type, if one exists, 
is passed to the dialogue processor module, step 813. 

After step 813 and step 807 if the next_type is a dialogue interface object, control passes to the 
dialogue processing module. The dialogue processing module uses the id to search for a dialogue header 

35 interface object in the object data manager, step 814. The dialogue processing module examines the 
interface object to determine if the dialogue is a ghost, step 815. Ghost dialogues have no user I/O 
associated with them. If the dialogue is not a ghost, then the dialogue processing module uses the option id 
to search for the dialogue options in the object data manager, step 816. The command_to__discover is 
executed to get the proper default values for the dialogue option interface objects, step 817. The proper 

40 representation of each dialogue option interface object is determined with reference to the linguistic and/or 
graphical environment. The representations along with the discovered value are sent for display to a screen 
library which enforces conformity by narrowing the interface to multiple graphical libraries, step 818. The 
screen library collects user input until the user indicates that the job is to be executed, step 819. After step 
819 and step 815 if the dialog is a ghost, the dialogue processing module examines the dialogue header 

45 object to determine if the user should be asked to reconsider the decision to execute the job, step 820. If 
yes, the user is asked, step 821. the response is received through the screen library, 822. If the user 
responds positively, step 823, or ask is false, step 820, then dialogue processing module will examine the 
command to execute in the dialogue header interface object, step 824. Any output or error messages that 
result from the execution of the command are displayed, step 825. A response is received from the user 

so indicating that the user has finished reviewing any output or messages, step 826. The dialoaue processing 
module redisplays the dialogue, step 827, and collects user input step 828. If the user indicates that the 
command should be executed again, step 829, then the dialogue processing module returns to step 824. 
On the other hand, if the user selects to exit, then control is passed to the menu processing module which 
redisplays the menu shown on entry to the interface tool, step 801. A third possibility is an indication to 

55 quit, step 831, which passes control to the processing module which displays the menu immediately 
preceding the dialogue. 

As shown in Table I, each object that is part of a menu has the structure as shown by 
sm_menu_option 200. If there are seven menu items, representing seven jobs, there would be seven of 

10 



» 039S646A2J _> 



EP 0 398 646 A2 



these sm menu option objects represented in the database with the same search key. 

As a user passes through menus, the idea is to successively refine the job that is to be accomplished. 
Each subsequent menu is therefore an exploded view of the previous item. Through these subsequ nt 

menus, the job will be refined to a single job. The next id 204 points to the next menu which is specified 

s in next_type 209 until next id 204 points to a dialogue specified by next type 209. Similar to menus not 

being static, a dialogue is not static, either. The fields in the dialogue are objects, of type 

sm command option 300 as shown in Table II, which meet the search criteria at that time. In addition, the 

owners of a command could present, in the interface shell, a newly implemented feature of that command 
by adding a new interface object into the database of type sm command option which met the same 

70 search criteria as the other fields in the dialogue. 

The sm command option object 300 represents just one field in the dialogue. If a dialog had several 

fields, there would be several of the sm command option objects. Each sm command option object 

300 has several items. The id 302 is the search criteria that is pointed to you by the previous interface 
object The id sequence number 303 specifies that for all objects that meet the id search criteria, they are 

75 to be presented in a certain sequence on the screen. For example, if a dialogue corresponded to a 
command that had 5 options, there would probably be 5 fields in the dialogue which would then- require 5 of 

the sm command option objects 300. Each object could then be numbered from 1-5. The name 305 is 

the field name which would actually appear on the screen. Since the preferred embodiment supports NLS 
(national language support) the name 305 is not actually used. Instead, there are three fields 306, 307, 308 

20 which relate to the translation facility. These three fields specify a file or catalog 306 having names in a 
message set 307 which contain the actual message id. These three fields 306, 307, 308 are used to extract 
a language sensitive string or context sensitive icon. Only if these three fields are 0 or the message facility 
fails is the actual name field 305 used. 

The type 309 is the method used to present the attribute represented by the interface object. Type 309 

25 determines the type of field, i.e. whether the field is to be managed as a numeric field, as a text entry field, 
or as a ring field where the options are finite, etc. In a ring field, the user is not able to enter text, but 
merely hits a key repetitively to increment through the available options. Another type of field is referred to 
as a file field. The file field allows a user to select from known file names which tend to be error prone if 
entered. The required item 310 specifies whether the field needs to be sent at every command execution. 

30 This is necessary because only fields that the user has changed are sent. This prevents having to re- 
establish the defaults. However, since some fields must always be sent, whether changed by a user or not, 
the required item 310 is needed. The prefix field 311 is generally the flag that goes with this option. 
Although it is not displayed to the user, the prefix field is what is actually used to build the command. 

The command to list 312, which is a regular operating command, is used to list the possible candidates 

35 for this one field. A user can position the cursor over the field and ask for LIST on that field and get all of 
the possible values. Command to list 312 is a command which produces standard out. For example, if a 
user wanted to print output to a printer but could not remember the name of the printers available, the user 
would select LIST. The interface tool would execute the command to list associated with the 
sm command option 300 that solicits the name of the target printer. Although this command to list is the 

40 same command that could be entered on a command line, instead of having the standard out of the 
executed command be directed to the screen, it is collected by this interface tool and put into the list panel 
4. The command itself is not sensitive to this distinction. The user would then be presented with a list of all 
the supported configured printers from which to select. The user may select from this list to provide the 
value needed. The command to list 312 may not always be present since there are some items, such as a 

45 sequential list of numbers, which do not warrant the execution of a command to list. 

The value items 314-318 indicates either the current value or the default value. For example, if the user 
task involved changing the configuration value of a printer, the user would need to know the current value 
and/or the default value. Again, fields 316-318, which relate to the message facility, are used since these 
values are also NLS sensitive as is the field name 305 as described above. For example if the value 315 

so had a value of "yes" or "no", the correct language for these values would be displayed to to user. The 
value index 314 indicates to the I/O routines which value in a ring is to be presented first. If the value index 
is zero, then the Oth element is presented first. 

Since the values that are sent to operating system commands are somewhat cryptic, the aix value 319 

is used. The aix_value 319 has the same format as the display value 315 in form, but not in content. For 

55 example, if the display values in the natural language support were "edge" and "centre", the operating 
system command does not actually use those values. The values "edge" and "centre" are the values 
displayed to the user, if the environment indicates English, but the values used by the operating system 
command may be just "e" and "c". If the user selects the second value, then the interface builds the 
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operating system command with the second aix__value. Help message id 320 is the contextual help for 
each individual item. 

The following is a further description of building a command. The interface tool uses a 2-pass model for 
collection of values. The first pass gathers all the values of the data objects, in order, the prefix field 31 1 of 

s which is either a null string or a flag. e.g. n -f n . These are the parameters that are not position-sensitive and 
must immediately follow the command name. The second pass gather all of the values, in order, the prefix 
field 311 of which is the reserved string, These are the parameters that are position-sensitive and 
follow the flagged options collected in the first pass. 

A special mechanism exists for passing strings collected in the name selector that immediately 

io precedes. The string may be either a "rawname". i.e., one selected by the user, or a "cookedname", i.e., 
the output of the cmd_to__ciassify 614. This (raw/cooked) name is a value which must have a data object 
defined for it. It will usually be the first object in the dialogue. The appearance on the screen of the instance 
selected ((raw/cooked) name) both facilitates the building of the command and increases the usability of the 
dialogue. The (raw/cooked) name either may or may not be preceded by a flag. 

is If the (raw/cooked) name has a flag, the data object sm cmd option allocated for it will be initialised 

with the proper flag in the prefix field. Because the disp values field will not be initialised from any 

cmd to discover that might be run for the dialogue as a whole, the dis; field name can be used to 

indicate that the value should be taken from the (raw/cooked) name instead. This is done by initialising the 
latter field with the reserved value, M rawname" or " cookedname". Initialising the required field to "yes", 

20 will cause the name to be sent, along with its flag, to the command, even though it is not changed in the 
dialogue. It should almost always be made a no entry field. Such values are not position-sensitive and will 
get picked up in the first pass as described above. 

If the (rawcooked) name does not have a flag, the data object sm__cmd option allocated for it will be 

initialised with n — n in the prefix field. Because the disp values field will not be initialised from any 

25 cmd to discover that might be run for the dialogue as a whole, the disc_field name can be used to 

indicate that the value should be taken from the (raw/cooked) name instead. This is done by initialising the 

latter field with the reserved value, " rawname" or " cookedname". Initialising the required field to "yes" 

will cause this name to be sent to the command, even though it is not changed in the dialogue. It should 
almost always be made a no entry field. These values will get picked up in the second pass as described 

30 above. Since they are position sensitive vis-a-vis one another, they should appear in the dialogue in the 
necessary sequence. 

The value index 314 is filled in from the header object class 400 (Table III). The header object 400 has 
a command to discover field 412 which executes an operating system command. The output from this 
command is captured by the interface tool and is used to fill in the values for all of the display values fields 

35 315 in the array of sm command option objects 300 that make up the dialogue. For example, if there is a 

command header 400 for "change printer characteristics", the command to discover is executed to 

discover the current characteristics of the printer. The output from the command_to_discover is then 
parsed by the interface toot to associate values with each individual interface object. For example, if the 
baud rate is represented in the output under the header, BR, then the value in that column is associated 

40 with the interface object whose discover field_name 304 is the string BR. Therefore, the interface shell is 

dynamically constructed based on the current state of the data processing system. The output from the 
commands that query the current state are presented to the user. The user can use the current state values 
displayed or select/enter other values. The command is built based upon a combination of current data and 
user specified data. 

45 Referring to Table III. the dialogue header object class 400 points to the interface objects that make up 

the dialogue. The id 402 is the search id. Also in the header is another key field, the command to exec 

408. The command to exec is the command that the dialogue executes. The command_Jo__exec is also 

the command that is logged. Commands that are used merely to list candidates or discover the current 
state, lateral or facilitating commands, are not logged, since these commands are peripheral to the task to 

so be executed. Lateral commands read system data. End job commands may also write system data. The^ 

end job is the command to execute 408 in the dialogue header 400. In this way, the log contains only the 

commands that are actually used to configure the users machine, rather than commands that were merely 

used to collect information to help the user configure the machined. By logging the command__to execute 

commands, the user can re-execute the log, and get exactly the same configuration subsequently. 

55 The ghost feature 41 1 in the header object 400 indicates that there is to be no I/O to the screen. In 
some instances, a dialogue with the user is not needed, but since the interface tool of this embodiment is 
data driven, the dialogue object exists. 

The above description is illustrated in the block diagram of the interface tool as shown in Fig. 2A. For 
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example, if a user wanted to 'perform system management tasks on the logical volume manager in the data 
processing system, the model used to accomplish this is shown by Fig. 2A. The menu 1A contains ail 
logical volume jobs from which the user can select. Some of these more general tasks include ADD 501 , 
SHOW 502, DELETE 503, CHANGE 505, and LI ST* ALL 506. In the ADD 501 model, the user goes straight 

s into the dialogue 14A after selecting ADD off of the logical volume . manager menu 1A. It would have a 
command_to__discover which would discover the defaults. Since the user has selected ADD 501 , the user 
is not working with an existing system resource; hence no current information exists. This distinction 
between discovery of defaults and discovery of current settings is of no functional importance to the 
interface shell. The user then fills in the information into the dialogue and executes the ADD 

70 command to exec. 

In using the SHOW 502 task, the user wants to see the characteristics of a system resource. Therefore, 
the interface has to be cognizant of which instance of this class of system resources to show. Therefore, the 

sm name select object 601 is required. For this example, the field would display to the user "name of 

logical volume". If the user knew the name the user wanted, the user would enter the name into the field. 

75 Since the name select object 601 also has a list feature 612. 613, the interface uses an operating system 
command to list the names of logical volumes in a panel for the user to select from. 

For other implementations of the SHOW command, a dialogue is not necessarily needed. However, as 
this example demonstrates, there could be different views of a system resource that a user might want to 
see> These different views are expressed in different execution parameters in SHOW 502. The dialogue for 

20 these different execution parameters allows users to select whether a limited amount of the data is to be 
shown, whether all of the data is to be shown, and to specify how the listing is to be shown, etc. The user 
interacts with the dialogue to make these determinations, executes the command, and receives output to 
the screen showing the data. 

A sm_name__select object 601 is also used for the DELETE 503 task since the user has to indicate to 

25 the interface shell the name of the system resource to be deleted. However, the dialogue header object 400 
is actually a ghost. A ghost dialogue means that there is no I/O to the screen. A dialogue is not presented to 
the user because no further information is needed. However, if the deletion of the system resource had 
varieties of function (e.g. delete from active use but save info in a retention file as opposed to delete 
completely), then a screen dialogue would follow for solicitation of the user's wishes. There are no dialogue 

30 objects 300 associated with a ghost. The header is sufficient to execute the end command. 

In the dialogue header object 400 there is an "ask" 409 field. If the "ask" 409 field is turned on, i.e. set 
to true, then the dialogue would display to the user "are you sure?". This ask function is useful for such 
tasks as deletion because it allows the user to verify that the user does indeed which to delete the item, if 
the user selects "yes", the DELETE command_to_execute 503 is executed. If the user selects no, the 

35 command is not executed. 

in the performance of a CHANGE task, unlike the ADD task, the system resource to be changed 
already exists. The sm_name_select object 601 is utilised to get the name of the object. The 
command__to_discover is executed, the current values of the attributes of the system resource are found, 
these current values and attributes are presented to the user in the dialogue, the user responses are 

40 collected, and the CHANGE command to execute 505 is executed. 

The sm_name_select 601 is not required for the LIST ALL task 506 since all of the names of the 
instances of this type of system resource will be used. The dialogue is a ghost dialogue since the user 
does not need to give any further instructions with this command. Therefore, the LIST ALL 
command to__execute is executed immediately and the user receives output to the screen. A ghost 

45 dialogue typically infers that there is no I/O to the screen for interaction with the user. However, the 
dialogue object 400 is still required since the command to execute 408 resides within this structure. 

A more complex example is shown in Fig. 2B with respect to the interface tool for managing printers or 
other physical devices in the system. To add a printer, a name select object 601 is required since, unlike 
logical volumes, all printers are not the same; they are diverse types. Therefore which dialogue object 400 

so is to be used is not known until the type is specified in the name select 601 facility. For example, to add a 
type A printer, one set of questions would be required in the dialogue, while if a type B printer were to be 
added another set of questions would be required in a dialogue. Therefore, to reach the correct dialogue 
object 400, the name__select object 601 would ask the user the type of printer. There are different ways in 
which the name 604 in sm__name_select is used. The string indicated in the next__id 603 could be the 

55 actual search key for the dialogue header 400, in which case the name value is not important. However, the 
name may be needed to find the next dialogue header 400. For example, if a user did not know what type 
of printer they wanted to deal with, the user could select LIST to get a list of all supported printers. In this 
case, the interface takes the "type" to find the appropriate dialogue object 400. However, to perform a 
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CHANGE 505 job, instead of changing a supported printer type, the user wants to change characteristics of 
an instance of a type of system resource, e.g. printer. The name of the instance might have been specified 
by the user and would then be very specific to the user's machine. It would not necessarily denote a type. 
If the user could not remember the machine specific name, the user would want to list the possible names. 

5 However, the list returned would not have the type names, but would have user specific names which the 
interface shell cannot understand in order to find the correct dialogue header object. 

Since these user specific names are not universal, a user interface tool can not provide any predefined 

dialogue objects 400 for each of these user specific names. Instead, within the sm name select object 

there is a command to classify 614 which correlates a user specific name to a printer type. The 

10 command to classify then executes and concatenates the name with the search field to find the correct 

corresponding dialogue object 400. 

For performing a SHOW task 502 for printers, the sm name select 602 is used to specify the name 

of the printer instance about which the user desires information. Since there is no further information that 
needs to be gathered, the SHOW command is executed directly, using the name selected, and the output is 

75 shown on the screen. 

Comparing Fig. 2B with Fig. 2A. a dialogue was used after the name select object 601 as shown in Fig. 
2A. There is nothing about the object itself which dictates whether a dialogue will follow a name select or 
not Instead, it is dependent upon the commands, and how the commands are implemented. For instance, 
in some cases, the devices that are to be shown may be quite complex and have a large number of 

20 different attributes. In those cases, adding a dialogue to the SHOW command allows a user to select which 
attributes are to be shown and in which way. For example, in a dialogue, a user may be able to specify a 
"quick search", "show all fields", or "show only specified fields", etc. in order to specify how the SHOW 
command is to be executed. For more simple devices without many attributes; 'showing all of the 
information on that device my involve merely showing the name and device type. In these simpler cases, a 

25 dialogue is not needed since all of the information will be shown after the user indicates the instance of the 
system resource by means of the name selector. 

If a name select object 601 is to follow immediately after a menu object class 200, the next type field 

209 in the menu object class 200 will specify a name select object. If a dialogue 400 is to follow 
immediately after a menu, the next type field 209 will specify a dialogue object. If another menu object is 

30 to immediately follow the menu, the next__type field 209 in the menu object will specify another menu 
object. The interface tool continues to get menus, and remains recursive through these same routines, until 

the "next type" field specifies a name select 601 or a dialogue 400. 

Referring back to Fig. 2B, a "communications"" menu 18 is shown leading to name select 601 for the 
CHANGE job. This merely illustrates that all of these jobs and actions can also be represented in another 

35 menu. Another menu can point into any one of these objects if it's next ID field 603 (Table IV) has the same 
search criteria as the other menu 1A. 

As shown in the detailed description, each job (including but not limited to SHOW, ADD, DELETE, 
CHANGE, LIST ALL) is totally data driven. The code that is running is not dependent upon the command 
that is to be executed, what field it is gathering information from, what path it is on, the previous steps 

40 performed, or the next steps to be performed. All of the instructions for traversal through the objects, the 
menus, name selects, and dialogues, and the execution of commands are all contained within the data, and 
not the code. When a first object is built that represents a menu, or a dialogue, or a name select, the next 
object within the traverse of objects is specified within the first object itself, and so on recursively 
throughout the objects comprising the interface tool of this embodiment. 

45 The interface tool of this embodiment can be used with all types of menus and dialogues to allow the 
menus, dialogues, tasks, and the execution of functions, including commands, to be data driven instead of 
predefined within code. 

The preferred embodiment utilises this interface tool as an interface to system management functions 
within a data processing system. One function of a system management facility is to provide configuration 

so tasks for system resources. For example, if a new device, such as a hard disk drive, printer, display, etc. 
were to be added to a system, the new device might need to be configured at some time. Previously the 
manufacturer of the system would have to have accounted for the possible reconfiguration of this device in 
the menus and code supplied with the configuration facility of the system. With the interface tool of this 
system, a manufacturer of devices does- not have to have the prior support from the manufacturer of the 

55 system. In order to manage new devices on a system no code has to be changed, and no code has to be 
recompiled. To add a device to the system, new interface objects are installed with the device driver code 
for the device. The new device interface objects only need to appear in one menu in order to give the user 
the ability to manage the device. The branch that presents the management job of the new device appears 



>_0398646A2J_> 



14 



EP 0 398 646 A2 



on a menu by virtue of a menu interface object having the same .search key as the other menu interface 
objects that form that m nu. The new object device would be added to the data repository such that the 
next time the configuration facility was run by a user, it would appear as if this new device was originally a 
part of the system management interface tool. This new device would then participate equally with all of the 

s other devices in the system management interface. 

With reference to Fig. 1B, all of the objects, the menu objects 200, the dialogue objects 300, the 
dialogue header objects 400, and the name objects 600, are contained within the objected oriented 
database labelled as the object data manager records 30. The system management interface tool 10 begins 
by getting the 'top menu object from the object data manager 10. All objects that have the same id 202 

io (Table I) are retrieved from the object data manager database 30 and presented by the interface tool 10. 
From this point on, the traversal through the objects (menus, names, dialogue), and the presentation of 
information from the objects, is determined by the data within the records, i.e. the objects themselves. 

This is illustrated with reference to Fig. 3. A top menu 701 is shown where one of its fields contains the 
actual text 205 displayed as "DEVICES" 205. If command to execute, and wants to use the interface tool to 

75 facilitate the entry of parameters and options, then the interface tool can be invoked with the command 
name as a parameter, which is the id of the dialogue header interface object which executes that command. 
This second approach is referred to as the fast path method. All objects, by virtue of having an id, can be 
reached by this fast path method by the user passing the id as a parameter in the invocation of the 
interface tool. The interface tool then searches for an object with the id of the parameter sent. The interface 

20 tool first searches for a dialog header object with the given id. If found, the corresponding dialogue interface 
objects are sent to the screen library and presented to the user as in step 814, Fig. 4, and processing 
continues as described above. If the dialogue- header is not found, the interface tool searches for a name 
selector object with the given id. If a dialogue is preceded by a name selector, then the command name is 
the id of the name selector rather the dialog header. If a name selector object is found, processing 

25 continues with step 808 as described above. Finally, the interface tool searches for a menu with the given 
id, and if found, processing continues with step 801 as described above. Since some commands are 
represented by more than one dialogue, passing the command name as a parameter can not be taken as 
an unambiguous reference to a single dialogue. Therefore, a command name is the id of the lowest object 
in the hierarchy which represents all significant instances of the command. In most cases, this is a dialogue 

30 header, but could be a menu. 

Another aspect of this fast path method is referred to as aliasing, as shown in Fig. 5A, 5B, and 5C. A 
situation may arise where more than one fast path token should point to the same node in the hierarchy. 
One token is the actual id of an object through which one would pass if the hierarchy were traversed from 
the top down. Other tokens, while not in the hierarchy, point to this token which is in the hierarchy. An alias 

35 is always a menu interface object 200, the alias field 210 of which has the value of true. The interface tool 
-finds the menu object to which the alias points, and processes it as if it had been selected. This allows the 
processing to begin at step 804, Fig. 4. In this way. alias can be used to point into the hierarchy at either a 
menu, Fig. 5A. a name selector, Fig. 5B, or a dialogue, Fig. 5C, while actually existing outside of the 
hierarchy. 

40 The above describes a fast path into the interface tool hierarchy. A facility also exists for escaping out 
of the tool into the command shell from which other applications or commands can be executed before 
returning to the point in the interface from which the user escaped. 

As shown in Fig. 1B the ASL layer is used to present the information to the user and collect user 
responses. The ASL layer is a screen library layer which protects the interface shell from dealing with 

45 differences in text or graphic libraries. Several presentation libraries 22, 23 can be interchanged to produce 
different presentation styles. The target graphic library may be chosen by the user at initialisation time or 
may be based on an external environment variable. These other support libraries may include presenting 
graphics and text to the user. Regardless of the presentation interface 20 used, the same objects within the 
object data manager database 30 are used. The data objects within the database are defined only once. 

so Each graphics library can then use its own symbols to present the information from the objects to. the user. 
These interchangeable graphic interfaces merely present the same information from the interface tool in 
different visual ways. 

Although the interface tool is protected from difference in graphics libraries by the ASL layer, the ASL 
layer enforces certain continuity and provides common function regardless of the graphics library bound to 
55 ASL. One such function is used when the logical frame presentation exceeds the size of the physical 
display area. The ASL layer shows the user the number of elements (data objects) which have been 
scrolled off of the screen in any direction. 

The various logical frame presentations that may be accessible by several system administrators having 
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various system authority can be controlled by applying access control policies to the interface objects. 
These access control policies can be applied to each interface object. A menu interface object name select 
interface object, or dialogue interface objects will not be found if the interface tool is operating in behalf if a 
user whose credentials do nof meet those that are in the access control list attached to the interface object. 
5 Each of the various interface objects are stored at only one location in the object database, and are 
assigned the appropriate access controls such that the various permutations of administrative views are 
dictated by the access control policy for the objects within the view. For example, administrator A may have 
read, write, and execute privileges for the user interface objects which present the conf igurable domain of 
TCP/IP, devices, and users, while administrator B may have read, write, and execute privileges for the user 
to interface objects which present the configurable domains of TCP/IP, SNA. devices, users, and systems. 
Therefore, it is possible to tailor the menus, dialogs, and options, that each administrator interacts wrth by 

j setting the appropriate access control policies on the various objects which define the user interface. 

| Another security method is inherent within the interface tool, since security is built into each of the 

commands that the interface executes. Since the interface tool uses the commands to alter the system 
is resource objects rather than altering these objects itself, any security filters in the command will be 
automatically applicable when the interface tool executes the command. If the user of the interface tool 
does not have permission to execute the command, the command itself will prevent the execution of the 
command, and the interface tool will return an error message to user that the command could not be 
executed. 

20 Although the preferred embodiment refers to configuration tasks and commands, the specific com- 
mands are not a part of the interface tool. Each command is merely a string in the command to execute 
field within the dialogue header interface object. To the interface tool, one command is the same as any 
other command. No special code is contained within the interface tool to execute the various commands. 
Therefore, this engine model for an interface tool is applicable not only to system management 
25 functions, but for any function which requires a function to be executed. Other functions, commands, and 
tasks may include those needed to read the mail, sending a note, etc. Any end user task can be executed 
with this interface tool by merely adding to the interface objects in the object data manager database. 

There has been described a user interface tool for displaying menus and dialogues to a user. The 
actual visual presentation to the user is performed by any screen library using the data from this interface 
30 tool. The interface tool is used in a preferred embodiment as the interface between a user and system 
management functions. The interface tool of this invention is a generic engine that has no knowledge of the 
individual instances of system management that it presents. The navigation through and presentation and 
collection of data are all directed toward the goaJ of calling an appropriate function in the application or 
system layer. This work can be done without special case knowledge because the interface tool is driven by 
j 35 self-defining, independent data objects which are sufficient to give direction to the interface layer for the 

: accomplishment of the above tasks. 

The menus, dialogues, and each instance of a system resource are represented as objects within an 
object database, and are referred to as interface objects. Data within these interface objects reflect the 
topology of the system resources. The interface tool traverses these interface objects based upon the data 
40 within the interface objects themselves and the user selections. 
; A distinction is made between interface data objects and system resource data objects, otherwise 

referred to as application data objects. System resource data objects define the workings of the system, are 
installed with the software (application or system) that control them, are read/write to the application layer, 
and are of no direct interest to the interface tool. 
45 The interface data objects define the workings of the interface, are installed with the software 
(applications) that they control, are primarily read-only to the interface tool, and are independent of other 
layers within the data processing system. The interface tool gets information that it needs, which is 
contained in the system resource data objects, via calls to functions in the application layer rather than by 
direct reference to this body of data. 
so The interface tool can independently execute any command, controlling all input and output. It therefore 
has access to, and control of, all system resources by execution of the appropriate command shell 
functions. 

Although a distinction exists in the above-mentioned groups of data, it is not technically necessary for 
the various groups to reside in different databases or to use different database referencing techniques. The 
55 lines between the groups are maintained without extra effort because the interface layer is designed to 
reference only those object classes about which it knows (see below for class definitions). There is no 
possibility of the interface tool being instructed to reference system data (or vice-versa), because such data 
is kept not only in different data objects, but in different classes of data objects, about which the interface 
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tool knows nothing. However, the method for referencing any class of data object will be the same. 

An object oriented interface model allows for highly flexible,, easily extendable interfaces. Pieces of the 
interface can be added or subtracted with minimum impact to the layer as a whole. With the addition of 
each new piece of software, interface objects can be added to the data repository, allowing newly installed 
s parts of the system to be managed in exactly the same way as parts that were the first to be designed. The 
problem of maintenance is diminished because the user who is extending or tailoring her/his interface does 
not edit large amounts of data (tables, programs, etc.), but rather creates new interface objects and adds 
them to the ones already in the repository. Without the need of re-compilation, the new objects appear in 
the desired environment the next time that the environment is entered because they will share a common id 
io key with the other objects in that environment and therefore be found by the interface tool 

While the invention has been particularly shown and described with reference to a preferred embodi- 
ment, it will be understood by those skilled in the art that various changes may be made without departing 
from the scope of the invention. 

APPENDIX Table I shows the structure of an interface menu option object, 
is Table II shows the structure of an interface dialogue command option object. 

Table III shows the structure of an interface dialogue header object. 

Table IV shows the structure of an interface name select object. 
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TABLE I 

SMIT MENU OBJECT CLASS (smjnenuopt) 

Each item on a menu in the SMIT tree corresponds to a menu 
object. The "menu" appearing on the screen is a set of these 
objects. 



struct sm _menu_opt { 

202^*id; r symbolic key for object 7 

203^*jd_seq_num; /* seq # for recs in this set 7 

2<w^*nextjd; /* symbolic key for next object 7 

205 — -text; /* describes task 7 

206 — *text_msgjile; /* Message Facilities catalogue name 7 

207— text_msg_set; r Message Facilities set id for name . 7 
<° 208^text_msgjd; /* Message Facilities message id for name 7 

209 s- next Jype; /* type of next action if this item picked 7 

210 ^ alias; /* is/is not fast path ptr to another screen 7 

211 ^-help_msgjd /* help system id/key for help text 7 

}; 
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TABLE II 
j-300 

SMIT DIALOGUE OBJECT CLASS (sm_cmdopt) 

Each dialogue (leaf) in the SMIT tree has an array of one or more 
options. Each option corresponds to a fields (parameter, option, 
or attributes) of the command that the dialogue performs. 



struct sm_cmd_opt { 

302- Ojd; J* symbolic key for object 7 

303- ^id_seq_num ; /* seq # for objects in this set 7 

304- «-*discJield_name; r output hdr from cmd_to_discover 7 

305— -*name; /* field name 7 

306— -* name_msg_file; /* Message Facilities catalogue for name 7 

307— name_msg_set; /* Message Facilities set id for name 7 
3oa--name_msg_id; /* Message Facilities message id for name 7 
309 *~ opJype; r method used to manage this field 7 

^ entryjype; r type of entry allowed in this field 7 

aaj^-entry.size; /* width of entry allowed in this field 7 

310 ^ required; /* is/is not rqd. for each exec of cmd 7 

311 ^ *P refix -' /* AIX cmd flag for this option 7 

313^" cmd_to_list_mode; /* amount of listed item to use 7 

312^" * cmd - t0 - list .' I* AIX cmd string for list of candidates 7 

^ cmd_to_list_postfix ; /* where to get cmd postfix, if any 7 

^- multi_select; /* multiple select from list is/is not valid 7 

s valuejndex; f zero-origin index of value string, if ring 7 

4 y*disp_values; /* current, default or allowed values 7 

315 y*values_msg_file; r Message Facilities catalogue for values 7 

316 x values_msg_set; /* Message Facilities set id for values 7 

31 ? r values_msg_id; r Message Facilities message id for values 7 

3i8-^*aix_values; r current, default or allowed values 7 

319 ^help_msg_id; /* help system id for help text 7 

320>Vcmd_to_validate /* AIX cmd string for validation 7 
325/ }; 
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TABLE III 

j- 400 

SMIT DIALOGUE HEADER OBJECT CLASS (sm_cmd_hdr) 

There is a header for each dialogue in the SMIT tree. 



struct sm_cmd_hdr { 

402-J*jd; 

403^*option_id; 

405 -*has_name_select ; 

404 -name; 

406~ name_msg_file ; 

407- name_msg_set ; 

410 -name_msgjd; 

408 ~*cmd_to_exec; 

409 '-ask; 

413 sexec_mode; 

4n;g host '. 
/*cmd_to_discover; 



r 
r 
r 
r 
r 
r 
r 
r 
r 
r 
r 
r 



j cmd_to_discover_postfix ;/* 



414 

r name size; 

415' • - • 
41 6 J 



rvalue size; 

417/,. 



/helpjnsgjd; 



r 
r 
r 



symbolic for object 
pointer to dialogue object 
is/is not preceded by a name selector* 
descriptive command name (task) 
Message Facilities catalogue file 
Message Facilities set id for name field 
Message Facilities id for name field 
AIX command string to execute 
assure that user wants to execute cmd 
command execution mode 
display or go straight to command 
cmd to fill in default/current values 
where to get cmd postfix, if any 
size of name field; default used if = 0 
size of value field; default used if = 0 
help system id/key for help text 
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TABLE 131 

SMIT NAME SELECT HEADER OBJECT CLASS 
(sm_name_hdr) 

10 

A name select header object may, if needed, be created for each 
dialogue that appears as the terminal node (leaf) in the SMIT 
application. This header points to one sm_cmd_opt object which 
is is used to solicit an instance of the object upon which the 
subsequent dialogue will act. (See above for specification of that 
object. ) 
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struct sm_name_hdr { 

602 '* id .' /* symbolic key for object */ 

603^-*next_id; /* symbolic key for next cmd hdr object */ 

605— - optionjd /* symbolic key for name selector cmd opt 7 

604 — name; r 

60s— *name_msg_file; f Message Facilities catalogue name 7 

so?— name_msg_set; r Message Facilities set id for name' 7 

60s— name_msg_id; /* Message Facilities message id for name 7 

609 type; /* method to process name selected 7 

610 ^ ghost; r display or go straight to listing 7 

6U j~ cmd_to_classify; r AIX cmd to classify name 7 

611 ^- help_msg_id; /* help system id/key for help text 
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45 Claims 

1. A user interface tool having means for presenting items for selection by a user of a data processing 
system for execution of the selected items, the interface tool comprising: 
means for representing a plurality of interface objects in an object database; and 

means for. dynamically associating different ones of the interface objects into a plurality of logical frame 
presentations based upon the data within each of the different ones of the interface objects. 

2. A user interface tool as claimed in claim 1 further comprising means for managing a screen 
presentation of the objects and a user interaction with the objects based upon the data within at least one of 
the plurality of interface objects. 

3. A user interface tool as claimed in claim 1 or claim 2 wherein at least one of the plurality of interface 
objects represents at least one attribute of at least one system resource. 

4. A user interface tool as claimed in claim 3 further comprising means for utilising a current value of 
the at least one attribute of the at least one system resource for presentation to the user. 
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5. A user interface tool as claimed in claim 3 or claim 4 further comprising means for utilising at least 
one instance of at least one of the system resources for presentation to the user for informing the user of an 
availability of the instance of th system resource. 

6. A user interface tool as claimed in claim 5 further comprising means for allowing the user to select 
s the instance of the system resource presented to the user. 

7. A user interface tool as claimed in claim 3 further comprising means for utilising a current value of 
the at least one attribute of the at least one system resource for a validation of a user response. 

8. A user interface tool as claimed in any preceding claim wherein at least two of the plurality of 
interface objects represent a hierarchical relationship between components of the data processing system 

70 based upon the data within each of the at least two interface objects. 

9. A user interface tool as claimed in claim 8 wherein the interface objects are dynamically associated 
according to the hierarchical relationship represented within each of the at least two interface objects. 

10. A user interface tool as claimed in claim 8 or claim 9 further comprising means for directly entering 
the hierarchy of interface objects at at least one of a plurality of locations within the hierarchy. 

15 11. A user interface tool as claimed in any preceding claim further comprising means for constructing a 
command by associating at least one user input value with an option within the at least one of-the interface 
objects. 

12. A user interface tool as claimed in claim 11 further comprising means for executing the constructed 
command. 

20 13. A user interface tool as claimed in claim 11 or claim 12 further comprising means for logging the 

executed command for later re-execution. 

14. A user interface tool as claimed in any preceding claim wherein the means for constructing and 

executing does so for a command based on a current state of the data processing system, a plurality of 

user selections, and the data within the interface objects. 
25 15. A user interface tool as claimed in any preceding claim further comprising means for retrieving the 

objects from the object database in response to the user selected item. 

16. A user interface tool as claimed in any preceding claim further comprising means for iteratively 

presenting the interface objects to the user dependent upon a plurality of user selections and the data 

within the interface objects. 

30 17. A user interface tool as claimed in any preceding claim further comprising means for accessing at 
least one interface object from a plurality of screen presentations. 

18. A user interface tool as claimed in any preceding claim further comprising means for accessing at 
least one screen presentation from a plurality of interface objects. 

19. A user interface tool as claimed in any preceding claim further comprising means for altering the 
35 interface object database from within the interface during a session of execution of the interface, and means 

for reflecting the altered interface during the same session of execution of the interface. 

20. A user interface tool as claimed in any preceding claim further comprising means for altering the 
interface object database by creating at least one new interface object 

21. A user interface tool as claimed in any preceding claim further comprising means for displaying the 
40 logical frame presentations by a plurality of graphical libraries. 

22. A user interface tool as claimed in any preceding claim further comprising means, within the 
interface data objects, for representing the items in the logical frame presentation in at least one of a 
plurality of ways dependent upon a graphical context. 

23. A user interface tool as claimed in any preceding claim further comprising means, within the 
45 interface data objects, for representing the items in the logical frame presentation in at least one of a 

plurality of ways dependent upon a linguistic context. 

24. A user interface tool as claimed in any preceding claim further comprising means for accessing a 
screen library having means for indicating to the user a number of the items in the logical frame 
presentation currently outside of a visual screen presentation to the user. 

so 25. A user interface tool as claimed in any preceding claim further comprising means for providing at 
least one logical frame presentation dependent upon at least one access control policy applied to the 
plurality of interface objects. 

26. A data processing system comprising a user interface tool as claimed in any preceding claim. 

27. A procedure for presenting items for selection by a user of a data processing system, the procedure 
55 comprising: 

representing a plurality of interface objects in an object database; and 

dynamically associating different ones of the interface objects into a plurality of logical frame presentations 
based upon the data within each of the different ones of the interface objects. 
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